Add LSPS1 server side support - #1053

This PR adds LSPS1 server side support to LDK Node, enabling a node to act as an LSPS1 service.

Details

The service exposes an LSPS1Service object that holds the LSPS1 supported_options and a local service_config object allowing the LSP to configure their fee details, signal BOLT11, BOLT12 and/or onchain payments support etc.

Client requests arriving via LSPS1ServiceEvent::RequestForPaymentDetails are kept in the store after validations per the spec requirements, and the LSP supported payment details sent back to the client via LSPS1ServiceHandler::send_payment_details.

Payments

BOLT11/BOLT12: When an LdkEvent::PaymentClaimable event arrives, we intercept early to check if the payment was an LSPS1 order payment, and goes ahead to claim it via ChannelManager::claim_funds if we find a matching payment_hash or offer_id in the store. Afterward, we open the channel and remove the order from the store.

Onchain Payments: After a wallet sync completes, we check to confirm if an LSPS1 payment did land in our onchain wallet, then opens the channel if we can find the payment via Wallet::list_confirmed_utxos().

Each payment option has an expiration window. Invoices has an expiration time, so we expect the client node to refuse paying an expired invoice. But Onchain payments are different, so if a client sends to the LSP's address after the expiration window, we trigger a refund back to the client's refund_onchain_address the total amount received minus the network fees.

There's a 24 hour window to remove orders from the store to avoid bloating. This is majorly for unpaid orders as paid orders are processed as soon as the payment arrives and removed from the store. But because there's no way to stop an LSP address from receiving payments when the order has been created and payment details sent out to the client. Such payments arriving when the order has been removed are forfeited.

Tests

Integration tests for the three payment options happy path are added.

Closes #917